One of the more developing areas of computer networking is the field of electronic conferencing. Conferencing provides the ability to have an electronic on-line "meeting" between a plurality of users on computer systems in a variety of locations. Users at a variety of sites may communicate with one another as if they were in the same room. Using such application programs, modem communication systems have enabled the ability to have a meeting wherein all users participate in the meeting through their individual computer systems and share data, graphics, text and other types of information. Users may communicate with one another sharing data in the form of graphical images, text or other annotations and other information represented on the computer system display. This is analogous to a meeting where participants in a face-to-face meeting may display information to one another on a whiteboard or blackboard and other participants may add annotations, delete or otherwise modify the board. It is also anticipated that as bandwidth of communication media improves and compression standards for graphical data also become more robust that recorded (or stored) video data may also be shared among a plurality of connected users during such teleconferences.
One of the requisites of an electronic conferencing system is the need to replicate the same data on all of the users' displays participating in the conference. Such systems typically implement this capability in a variety of ways. The most common is the client/server model wherein a single connected node acts as a "server" of other nodes in the system and the remaining nodes connected in the conference act as slaves or clients to the server process. Thus, each of the clients merely receive data from the central machine to update their displays. Such systems, however, are entirely dependent upon the service being provided by the server and the throughput of the communication medium. Obviously, systems wherein the clients merely act as displays and inputs for user requests suffer from severe performance problems due to resulting updates of data from the server, which is typically handled serially by the server.
Another prior art solution for maintaining all of a participant's display in a conferencing system synchronous rely on a distributed client/server system. In a distributed client/server approach a shared object structure is kept on the server and clients are made aware of changes of that distributed information through alerts or demons. The disadvantage of this approach, similar to the centralized client/server approach is the reliance on the architecture itself. This includes a data conferencing application which must be able to connect several users over a phone line from point to point without requiring access to a centralized common server.
In the client/server approach, moreover, performance suffers greatly because requests to add or delete objects such as annotations, graphical images or other information on a participant's display is entirely dependent upon communication from the server. Thus, real-time performance severely suffers in prior art client/server models since approval to act and manipulate upon objects on a participant's display is entirely dependent upon a whole set of dependent variables such as the number of requests to the server pending, the throughput of the communication medium, the number of participants connected, etc.
Yet another prior art approach for maintaining synchronicity of a plurality of participants in a conferencing system is the use of a distributed object-oriented system.
This is a generalized approach which relies upon extensions, in one prior art solution, of the SmallTalk language itself. In this prior art system, "local" objects send messages to "proxy" objects which are local representatives for objects in the "shared" object space. The proxy objects communicate with the real objects through an RPC (Remote Procedure Call) mechanism. RPC is a protocol governing the method with which an application activates processes on other nodes and retrieves the results. Such a conventional mechanism is defined by Sun Microsystems, Inc. and described in RFC-1057 that provides a standard for initiating and controlling processes on remote or distributed computer systems.
The problem with this approach is in its generality which requires extensive support for sharing any object while making no assumptions about the behavior of objects. This has two disadvantages. First, a complex "SmallTalk system" is needed to support the distribution of objects in general. Second, the concurrency problem for any object is difficult because multiple participants may have different objects in their systems and such different objects may not be able to be communicated to the remaining users.
Certain issues arise when large amounts of data, such as Binary Large OBject (BLOB) data, are transferred during an electronic conference. For example, a user's system may experience a delay in the refresh of the screen if the CPU of that system is busy transferring the BLOB. Additionally, the transfer of a BLOB may need to be reprioritized if a request for a different BLOB is received. For more information about the transfer of large object data in an electronic conferencing system, please see U.S. Pat. No. 5,452,299, entitled "Optimized Transfer of Large Object Data Blocks in a Teleconferencing System," which is incorporated herein by reference.
The issues associated with the transfer of BLOBs are multiplied in a multipoint conference compared to a point-to-point conference. A multipoint conference is a conference in which there are three or more participants. In a point-to-point conference, only two participants are conferenced together. In a multipoint conference, for example, extra bookkeeping is required to keep track of which data has been provided to which participants. While the present invention is particularly useful in a multipoint conference, the present invention is also applicable to a point-to-point conference.